Modern medical technology employs a large number of rather expensive and sophisticated echo apparatuses. Examples for such medical apparatuses are computer tomographs (CT), positron emission tomographs (PET) or other medical modalities. Other medical apparatuses include intensive care apparatuses. Those medical apparatuses are normally connected in a communication network in a modular fashion. Those medical apparatuses are connected via a suitable communication network. The peripheral devices are ranged for example to collect measurement data from patients. Examples of peripheral devices are injectors, respiration apparatuses, EKG monitors, amplifiers or devices for controlling respiration dating.
For the purposes of communication the peripheral devices are equipped with a specific protocol as a communication interface.
One of such protocol, specifying a communication interface is the so called CANopen interface, which is mainly used for embedded systems in automation. Each peripheral device or indeed any device complying with the standards specified in the CANopen protocol is called a CANopen device. The CANopen standard DS301 is a basic profile. In this standard there is provided a description of the communication functionality and of the device specific objects by means of an electronic data sheet (EDS). The EDS comprises background and meta-information relating to the device and is an electronic file, which usually is saved on the device itself. The CANopen standard is—referring to the OSI layering—the layer 7 communication protocol and is known particular from the field of automation technology but is also widely used in the field of medical technology.
According to the CANopen standard parameters and states of each CANopen device are described by means of objects arranged in tabular fashion in the EDS. The EDS for a particular CANopen device is normally available from the vendor. The data objects in the EDS are normally sufficient to describe how to access device parameters or settings. However, more complex accesses for example for the purposes of updating the CANopen device with loadware are not described sufficiently. The standard data objects in the EDS are not “rich enough” to describe such complex processes as a loadware update.
The CANopen device is normally provided with one or more microcontrollers onto which an application is loadable in order to enable the functionalities of the CANopen device.
As an example for an EDS file, known in the state of the art FIG. 1 shows parts of this file with relevant passages for example comprising an object having a number X1F50. This object comprises a number of sub objects which are shown in FIG. 1, for example the sub object 1f50sub1.
Generally, the first lines are specifying an object type a parameter name a data type, an access type and a PDO (process data object) mapping.
However, in the state of the art, there is an issue with those sub objects in that they do not supply sufficient details for example relating to which memory ranges are available for the update in the buffer of the loadware on the CANopen device. Therefore, in prior art systems the vendor had to supply further information on separate channels to enable an update of loadware. This process is, however, error-prone and non economical. For example, the vendor had to specify where the memory is located, which pages in memory are reusable in order to note the loadware onto and for example which one of sub objects is suitable for starting the up-loaded loadware.